In a network or cluster of elements, the System Data Synchronization feature keeps programming data, such as Interconnect Handling Restrictions, Feature Access Codes, and Class of Service Options, identical at each element.
Without the System Data Synchronization (SDS) feature, you would need to log into each element and manually program the data to be the same, or program a master database and then restore it to each element. Then, you would need to make all future modifications of system data on each element to keep the network and/or cluster element databases in sync.
The SDS feature reduces the time required to set up and manage networks and/or clusters of MiVoice Business systems by allowing you to
compare the data in a programming form of one system against the data in same form on another system.
start sharing system form data among a network or cluster, or group of elements (MiVoice Business systems)
synchronize the form data from a master element across the forms on the other elements within the
network,
cluster, or
element group (for example, an Administrative Group).
maintain the telephone directories on all the elements in the network or cluster (see Remote Directory Number Synchronization).
After a network or cluster has been set up with SDS, all adds, modifications, and deletions to the data that you have designated as shared are automatically distributed to the other elements in the network or cluster at the specified scopes.
In resilient configurations, SDS also synchronizes the data of resilient users and devices between primary and secondary controllers. After you set up data sharing between the primary and secondary controllers, the application automatically keeps user and device data, such as feature key programming and DND settings synchronized between the primary and secondary controller regardless of whether the changes are made on the primary or secondary controller:
If resilient users modify their set programming while their sets are being supported on the primary controller, SDS automatically updates the secondary controller with the changes.
If resilient users fail over to their secondary and modify their set programming, SDS updates the primary controller with the changes after the primary controller returns to service.
If an administrator updates resilient user and device data on either the primary of secondary controller, SDS automatically updates the database of the other controller.
SDS allows form data to be shared among MiVoice Business elements at the following scopes:
All Network Elements: distributes updates to all network elements that support SDS.
All Cluster Members: distribute updates to all MiVoice Business cluster elements.
All 3300 ICP: distribute updates only to the MiVoice Business systems in the network. This encompasses all server-based MiVoice Business platforms and 3300 ICP controllers.
Network Group Members: this option is for future use.
Admin Group Members: distribute updates to all elements that belong to the administrative group. Use administrative groups to share data among groups of elements within a network group.
Resilient Pair: distribute resilient user and device data between a primary and secondary controller.
Member Hosts: distribute group information and group member data (for example, cluster pickup groups information and cluster pickup group members) between all the elements on which the group members reside. This sharing scope does not apply to network hunt groups or resilient ACD hunt groups.
Hospitality Gateway and Guest Room Host: distribute updates to all MiVoice Business elements in the hospitality cluster.
Hospitality Gateway and Suite Host: distribute updates to all MiVoice Business elements in the hospitality cluster.
None: do not distribute the form data.
The following illustration shows an example of Feature Access Codes (FAC) being shared at the network scope and Call of Restriction (COR) settings being shared at the administrative group scopes.
In the following illustration
all systems (A, B, C, D, E, F, G, and H) share FAC data at the network scope
systems C and D share COR data at the administrative group 1 scope
systems G and H share COR data at the administrative group 2 scope
The following illustration shows an example of Feature Access Codes (FAC) being shared at the network scope while the Class of Service (COS) settings are shared at the cluster scope only. In the following illustration
systems A, B, C, and D share FAC data at the network scope
systems A and B share COS data at the cluster scope
system C and D share COR data at the cluster scope
In the above example, SDS would be configured such that
COS changes on system A would only be distributed to system B; and COS changes on system B would only be distributed to system A
COS changes on system C would only be distributed to system D; and COS changes on system D would only be distributed to system C
FAC changes on any of the four systems would be distributed to all other systems (A, B, C, and D).
At the resilient pair scope, SDS shares the selected device data, user data, and user-managed data between the primary controller and the secondary controller. In the following example, SDS would be configured such that
User and device changes on system A (primary) would only be distributed to system B (secondary)
User and device changes on system B (secondary) would only be distributed to system A (primary).
For example, if the user at extension 3000 programs a feature access key on his or her set while on the primary controller (System A) , SDS distributes the programming update for the new key to the user's secondary controller (System B), but not to System C or System D. Likewise, if the user's set is on the secondary controller (System B) and the user programs a feature access key, SDS distributes the programming update for the new key to the user's primary controller (System A), but not to System C or System D.
At the member hosts scope, SDS shares the group information and group membership data between the elements in a cluster. In the following example, SDS maintains the call pickup group information and call pickup group membership on the cluster elements.
